### Rozdział. Performance budowania frontu – jak system komponentów i design tokens przyspiesza każdy kolejny ekran

Front nie zwalnia dlatego, że brakuje kreatywności. Zwalnia, gdy każdy nowy ekran jest „od zera”: nowe style, nowe odstępy, nowe odcienie, nowe warianty przycisków. Po kilku sprintach pojawia się dług techniczny i wizualny: niespójne marginesy, duplikaty kolorów, cztery wersje tego samego komponentu. Lekiem nie jest jeszcze jeden framework, tylko system: mały język projektowy (design tokens) i biblioteka komponentów/bloków z jasnymi zasadami użycia. Dzięki temu budujesz szybciej, spójniej i z mniejszą liczbą błędów. Ten rozdział pokazuje, jak taki system ułożyć „na lekko”, by przyspieszyć pracę od pierwszego tygodnia.

#### Czym są design tokens – Twoje „atomy” wizualne

Design tokens to nazwy i wartości, które opisują fundamenty interfejsu: kolory, typografię, odstępy, promienie zaokrągleń, cienie, a nawet czas i krzywe animacji. Zamiast pisać w CSS „#1A73E8” albo „16px” – używasz nazw: `--color-primary-600`, `--space-4`, `--font-size-base`. Zyskujesz trzy rzeczy naraz: spójność, szybkość i łatwe skalowanie (np. tryb ciemny, rebranding).

- Przykładowy zestaw tokenów (w CSS Custom Properties)
  ```css
  :root {
    /* Kolory */
    --color-primary-600: #1a73e8;
    --color-primary-700: #1558b0;
    --color-neutral-900: #0f172a;
    --color-neutral-600: #475569;
    --color-neutral-100: #f1f5f9;
    --color-accent-600: #10b981;
    --color-danger-600: #ef4444;

    /* Typografia */
    --font-family-sans: "Inter", system-ui, -apple-system, Segoe UI, Roboto, Arial, sans-serif;
    --font-size-xs: 12px;
    --font-size-sm: 14px;
    --font-size-base: 16px;
    --font-size-lg: 18px;
    --line-height-tight: 1.2;
    --line-height-normal: 1.6;

    /* Odstępy (8‑punktowa siatka) */
    --space-1: 4px;
    --space-2: 8px;
    --space-3: 12px;
    --space-4: 16px;
    --space-5: 20px;
    --space-6: 24px;
    --space-8: 32px;
    --space-10: 40px;

    /* Promienie i cienie */
    --radius-sm: 6px;
    --radius-md: 10px;
    --shadow-sm: 0 1px 2px rgba(0,0,0,.06);
    --shadow-md: 0 4px 12px rgba(0,0,0,.12);

    /* Ruch */
    --ease-standard: cubic-bezier(.2,.8,.2,1);
    --duration-fast: 150ms;
  }
  ```
- Jak to działa w praktyce
  - Chcesz przyciemnić kolor przewodni? Zmieniasz jedną wartość – cały interfejs się dostosuje.
  - Potrzebujesz dark mode? Nadpisujesz tokeny w `@media (prefers-color-scheme: dark)` lub na `body[data-theme="dark"]`.
  - Zmieniasz rozmiary globalnie (np. większa baza 18 px) – treść staje się czytelniejsza bez ręcznego poprawiania setek miejsc.

Tokenujesz to, co jest „systemową decyzją”, nie każdy piksel. Reguła: mniej, ale sensownie.

#### System komponentów/bloków – klocki, z których składasz strony

Komponent to samowystarczalny element interfejsu ze swoim wyglądem i zachowaniem: przycisk, pole formularza, karta produktu, nawigacja, alert. Blok (section) to większy moduł z kilku komponentów: hero z nagłówkiem i przyciskiem, pricing table, listy artykułów. Biblioteka to katalog tych klocków z opisem, jak ich używać.

- Jak zacząć lekko (bez budowy korporacyjnego „design systemu”)
  1) Inwentarz UI: przeglądasz istniejące widoki i spisujesz, co powtarzasz. Zwykle wystarczy 12–20 komponentów bazowych.
  2) Wersje i stany: dla każdego komponentu definiujesz stany (domyślny, hover, aktywny, disabled, error/success dla pól).
  3) Warianty: rozmiary S/M/L, warianty wizualne (primary/secondary/ghost). Każdy wariant ma sens – unikaj mnożenia bytów.
  4) Dokumentacja minimum: krótki opis, do czego służy, przykładowe użycie, co robić/nie robić (np. „nie używać przycisku ‚ghost’ na ciemnym tle”).

- Przykład komponentu z tokenami (przycisk)
  ```css
  .btn {
    font-family: var(--font-family-sans);
    font-size: var(--font-size-base);
    line-height: var(--line-height-tight);
    padding: var(--space-3) var(--space-5);
    border-radius: var(--radius-sm);
    border: 1px solid transparent;
    transition: background-color var(--duration-fast) var(--ease-standard),
                box-shadow var(--duration-fast) var(--ease-standard);
    cursor: pointer;
  }
  .btn--primary {
    color: #fff;
    background: var(--color-primary-600);
  }
  .btn--primary:hover {
    background: var(--color-primary-700);
    box-shadow: var(--shadow-sm);
  }
  .btn--ghost {
    color: var(--color-primary-600);
    background: transparent;
    border-color: var(--color-primary-600);
  }
  .btn--danger { background: var(--color-danger-600); color: #fff; }
  .btn--sm { padding: var(--space-2) var(--space-4); font-size: var(--font-size-sm); }
  .btn--lg { padding: var(--space-4) var(--space-6); font-size: var(--font-size-lg); }
  .btn:disabled { opacity: .6; cursor: not-allowed; }
  ```
- Blok „hero” jako sekcja złożona z komponentów
  ```html
  <section class="hero">
    <h1 class="hero__title">Przyspiesz swoją stronę bez przepisywania jej od nowa</h1>
    <p class="hero__lead">Checklisty, case’y i narzędzia, które realnie skracają LCP i INP.</p>
    <div class="hero__actions">
      <button class="btn btn--primary btn--lg">Odbierz checklistę</button>
      <a class="btn btn--ghost btn--lg" href="/case-studies">Zobacz case studies</a>
    </div>
  </section>
  ```
  Styl „hero” odwołuje się wyłącznie do tokenów (kolory, spacing, typografia). Dzięki temu temat, rozmiary i kontrasty pozostają spójne w całym serwisie.

- Zasada „kompozycji, nie dziedziczenia”
  - Zamiast potężnych, sztywnych komponentów, buduj mniejsze elementy i składaj je (np. `Card` + `Badge` + `Button`). Łatwiej je wymienić i testować.

#### Zasady użycia – kiedy, jak i po co

Biblioteka bez zasad szybko zamienia się w „sklepik z klockami”. Dodaj lekkie, praktyczne reguły.

- Skala odstępów i siatka
  - Trzymaj 8‑punktową skalę (4/8/12/16/24/32/40 px). Dzięki temu sekcje „oddychają”, a interfejs nie wygląda jak patchwork.
  - W komponentach używaj tokenów `--space-*`. Nie wpisuj „magicznych” wartości – dziś dopasujesz, a jutro rozsypiesz rytm.

- Kontrasty i dostępność
  - Dla przycisków i linków zdefiniuj pary kolorów spełniające WCAG AA. Zakoduj je w tokenach (np. `--button-primary-fg`, `--button-primary-bg`), by nikt nie tworzył własnych, zbyt jasnych kombinacji.

- Limity wariantów
  - Jeśli komponent ma >3 wariantów, sprawdź, czy wszystkie mają realne zastosowanie. Wąska paleta = szybsze decyzje i mniej CSS/JS.

- Nazwy i konwencje
  - Ustal precyzyjny schemat nazewnictwa klas (np. BEM: `component__element--modifier`) i trzymaj się go. To zmniejsza konflikt stylów i przyspiesza onboarding nowych osób.

- Reuse ponad copy‑paste
  - Zamiast tworzyć „nowy” przycisk na potrzeby kampanii, modyfikuj istniejący przez modyfikator (np. `btn--accent`). Komponenty mają być wielokrotnego użytku – to esencja prędkości.

#### Jak utrzymywać bibliotekę – lekki design system w praktyce

- Jeden „source of truth”
  - Tokeny trzymaj w jednym pliku/źródle (CSS variables, Style Dictionary, Tailwind config). Generuj z nich motywy (light/dark) i eksporty do Figma (jeśli projektujesz w narzędziu).
- Storybook/Playroom (opcjonalnie, ale bardzo pomocne)
  - Prosta przeglądarka komponentów z przykładami stanów i wariantów. Deweloper widzi, testuje i kopiuje gotowe wzorce.
- Kontrola zmian
  - Wersjonuj bibliotekę (semver). Zmiany łamiące („breaking”) komunikuj w changelogu. Minimalizujesz „niespodzianki” w istniejących widokach.
- Testy wizualne i dostępności
  - Dodaj snapshoty wizualne (Percy/Chromatic) dla kluczowych komponentów oraz testy a11y (axe). Wczesna detekcja regresji oszczędza godziny.

#### Wydajność jako cecha systemu, nie „ostatni krok”

Gdy tokeny i komponenty są bazą, wydajność przychodzi w pakiecie.

- Mniej CSS, mniej JS
  - Reużywalne komponenty = mniej unikatowych stylów. Jeżeli używasz utility‑first (np. Tailwind), zastanów się nad ekstrakcją powtarzających się wzorców do komponentów – HTML będzie czystszy, a styl spójniejszy.
- Lepsze Core Web Vitals
  - Przewidywalne rozmiary i spacing ograniczają CLS (skoki layoutu). Wspólne wzorce lazy‑load i hasełka do obrazów (ratio boxy) trzymają LCP/INP w ryzach.
- Mniejsza liczba błędów
  - Jeden naprawiony błąd w komponencie naprawia cały serwis (np. focus ring w przyciskach).

#### Jak wdrożyć w 2–3 tygodnie bez „rewolucji”

- Tydzień 1: tokeny i 6 komponentów bazowych
  - Zdefiniuj paletę (primary, neutral, accent, danger z tonami), typografię, spacing. Zbuduj: Button, Input, Select, Checkbox, Alert, Card. Podmień je w 1–2 kluczowych widokach.
- Tydzień 2: bloki i zasady
  - Złóż 3 bloki (Hero, Pricing, Listę artykułów). Spisz zasady: skala odstępów, warianty, nazewnictwo, kontrasty. Dodaj krótką stronę „Księga frontu” w repo/Wiki.
- Tydzień 3: porządki i automatyzacja
  - Usuń duplikaty stylów, zamień twarde wartości na tokeny, ustaw testy a11y pod storybookiem. Zrób mini‑szkolenie dla zespołu (30–45 min).

Po tych trzech tygodniach nowe podstrony powstają z klocków, a nie z „kleju”. Czas wdrożenia spada, a spójność rośnie sama.

#### Najczęstsze potknięcia i jak ich uniknąć

- Za dużo tokenów na start – zacznij od 30–50. Resztę dodawaj, gdy pojawi się realna potrzeba.
- „Specjalny” komponent dla każdej kampanii – najpierw sprawdź, czy nie da się tego zrobić wariantem istniejącego.
- Ręczne wpisywanie kolorów i pikseli – wymuś code review: twarde wartości tylko w tokenach/globalnych miejscach.
- Brak dokumentacji użycia – nawet jedna strona README z przykładami i „do/don’t” oszczędza godziny pytań.
- Brak odpowiedzialnego – wyznacz właściciela biblioteki (może być rotacyjnie), który scala PR‑y i pilnuje zasad.

### Podsumowanie rozdziału

Design tokens dają język, którym opisujesz wygląd i zachowanie interfejsu. Biblioteka komponentów i bloków daje klocki, z których szybko składasz strony. Razem tworzą mały, ale skuteczny system, który przyspiesza pracę, trzyma spójność i poprawia wydajność bez nadludzkiego wysiłku. Gdy każdy ekran powstaje z tych samych, dobrze opisanych elementów, zmiany są tańsze, ryzyko błędów mniejsze, a użytkownicy widzą i czują porządek. To jest właśnie performance budowania frontu: mniej improwizacji, więcej systemu – i praca idzie jak po sznurku.